Generally, in image compression, an uncompressed image is processed to obtain a compressed image. The image processing includes application of one or more algorithms to the uncompressed image. As an example, one such algorithm for image compression is joint photographic experts group (JPEG).
One type of image is called a texture map or a texture. A texture map is an image that is applicable to a surface of a two-dimensional or three-dimensional object (for example, an object that is represented in a virtual space by a wireframe model that includes one or more polygons). Similar to images, texture maps are compressed using one or more image compression techniques to obtain compressed textures which are easily stored in a database or quickly communicated over a network. Advanced scalable texture compression (ASTC) is a standard compression technique and is predominantly used for texture compression.
It is common in computer graphics systems to generate colors for sampling positions in an image to be displayed by applying textures or texture data to the surfaces to be drawn. For example, surface detail on objects may be generated by applying a predefined “texture” to a set of graphics primitives (such as polygons) representing the object, to give the rendered image of the object the appearance of the texture. Such textures are typically applied by storing an array of texture elements or “texels,” each representing given texture data (such as color, luminance, or light/shadow values) at a given location (i.e., position), and then mapping the texels onto the corresponding elements, such as a set of sampling positions, for the image to be displayed. The stored arrays of texture elements (i.e., data) are typically referred to as texture maps.
Such arrangements can provide relatively high image quality, but have a number of drawbacks. In particular, the storage of the texture data and accessing it in use can lead to higher storage capacity and processing requirements on a graphics processing device. This is particularly significant for power constrained devices, such as mobile phones and other handheld devices that perform graphics processing, as these devices are inherently limited in their storage, bandwidth, and power resources. It is therefore known to encode such texture data in a compressed form so as to reduce the storage and bandwidth that may be imposed on a graphics processing device when using textures.
Texture compression techniques typically determine a reduced set or palette of colors (or other data) to be used for a given texture map and then store, for each texture element (texel) in the texture map, an index into the set or palette of colors that indicates the color to be used for the texture element. This has the advantage that only an index, rather than a full color, value needs to be stored for each texel. The existing texture compression techniques use block-based encoding, in which the overall array of texture elements to be encoded is divided into an array of small blocks (such as blocks of 4×4 texels or 8×8 texels), with each such block then encoded (compressed), and decoded, separately. This can help to make the decoding process more efficient, because the decoder, for example, may need to decode only one or a few of the encoded blocks to determine the value of a texel of interest, rather than the entire encoded texture.
In the conventional mechanisms, the ASTC compression is an offline encoding system. The ASTC encoder is a block-based, texture compression standard. In an ASTC coder/decoder (codec), all texels of a block are represented using color endpoints and weights, which is compressed to a pre-defined 128 bits with best possible quality. In the current smart phone or tablet market, there are real time ASTC decoders to provide a user with a differentiating gaming experience. In the gaming ecosystem, the need for an ASTC encoder is not much prevalent. But to deploy the ASTC compression for the imaging compression context, leads to the desirability of a real-time ASTC encoder. In an ASTC encoder, a block mode selection follows a complex and an iterative approach, which is not a viable solution for real-time encoding applications. The block mode selection algorithm is described below.
A best block mode and color endpoint mode (CEM) are selected based on predefined 128 bits and Min (Weight error [NB]+Color format choice error [CF] criteria), where NB=0, 1, 2, 3 . . . number of blocks and CF=0, 1, 2, 3 . . . number of color formats, weight error=(weight decimation error+weight quantization error), which can fit into predefined 128 bits.
There is a need in the art to provide a low-complexity block-mode selection method to handle real-time encoding applications.